Metamodel references:
Definitions and Usages
The modeling capabilities of SysML facilitate reuse in different contexts. Definition and usage elements provide a consistent foundation for many SysML language constructs to provide this capability, including attributes, occurrences, items, parts, ports, connections, interfaces, allocations, actions, states, calculations, constraints, requirements, concerns, cases, analysis cases, verification cases, use cases, views, viewpoints and renderings.
In general, a definition element classifies a certain kind of element (e.g., a classification of attributes, parts, actions, etc.). A usage element is a usage of a definition element in a certain context. A usage must always be defined by at least one definition element that corresponds to its usage kind. For example, a part usage is defined by a part definition, and an action usage is defined by an action definition. If no definition is specified explicitly, then the usage is defined implicitly by the most general definition of the appropriate kind from the Systems Library (see
9.2
). For example, a part usage is implicitly defined by the most general part definition Part from the model library package Parts.
Features
A definition may have owned usage elements nested in it, referred to as its features. A usage may also have nested usage elements as features. In this case, the context for the nested usages is the containing usage. A simple example is illustrated by a parts tree that is defined by a hierarchy of part usages. A vehicle usage defined by Vehicle could contain part usages for engine, transmission, frontAxle, and rearAxle. Each part usage has its own (implicit or explicit) part definition.
A feature relates instances of its featuring definition or usage to instances of its definition. For example, a mass feature with definition MassValue, featured by the definition Vehicle, relates each specific instance of Vehicle to the specific MassValue for that vehicle, known as the value of the mass feature of the vehicle.
A usage can also be contained directly in an owning package. In this case, the usage element is considered to be an implicit feature of the most general kernel type Anything. That is, a package-level usage is essentially a generic feature that can be applied in any context, or further specialized in specific contexts (as described under Specialization below).
A usage may have a multiplicity that constrains its cardinality, that is, the allowed number of values it may have for any instance of its featuring definition or usage. The multiplicity is specified as a range, giving the lower and upper bound expressions that are evaluated to determine the lower and upper bounds of the specified range. The bounds must be natural numbers. The lower bound must be finite, but the upper bound may also have the infinite value *. An upper bound value of * indicates that the range is unbounded, that is, it includes all numbers greater than or equal to the lower bound value. If a lower bound is not given, then the lower bound is taken to be the same as the upper bound, unless the upper bound is *, in which case the lower bound is taken to be 0. For example, a Vehicle definition could include a usage element called wheels with multiplicity 4, meaning each Vehicle has exactly four wheels. A less restrictive constraint, such as a multiplicity of 4..8, means each Vehicle can have 4 to 8 wheels.
A usage may be referential or composite. A referential usage represents a simple reference between a featuring instance and one or more values. A composite usage, on the other hand, indicates that the related instance is integral to the structure of the containing instance. As such, if the containing instance is destroyed, then any instances related to it by composite usages are also destroyed. For example, a Vehicle would have a composite usage of its wheels, but only a referential usage of the road on which it is driving.
Note. The concept of composition only applies to occurrences that exist over time and can be created and destroyed (see
7.9
). Attribute usages are always referential and any nested features of attributes definitions and usages are also always referential (see
7.7
).
Specialization
Definition and usage elements can be specialized using several different kinds of specialization relationships.
A definition is specialized using the subclassification relationship. The specialized definition inherits the features of the more general definition element and can add other features. For example, if Vehicle has a feature called fuel, that is defined by Fuel, and Truck is a specialized kind of Vehicle, then Truck inherits the feature fuel. An inherited feature can be subsetted or redefined as described below. The Truck definition can also add its own features such as cargoSize.
A definition can specialize more than one other definition, in which case the definition inherits the features from each of the definitions it specializes. All inherited features must have names that are distinct from each other and any owned features of the specializing definition. Name conflicts can be resolved by redefining one or more of the otherwise conflicting inherited features (see below).
A usage inherits the features from its definition in the same way that a specialized definition inherits from a more general definition element. For example, if a part usage vehicle is defined by a part definition Vehicle, and Vehicle has a mass defined by MassValue, then vehicle inherits the feature mass. In some cases, a usage may have more than one definition element, in which case the usage inherits the features from each of its definition elements, with the same rules for conflicting names as described above for subclassification. A usage can also add its own features, and subset or redefine its inherited features. This enables each usage to be modified for its context.
A usage can be specialized using the subsetting relationship. A subsetting usage has a subset of the values of the subsetted usage. The subsetting usage may further constrain its definition and multiplicity. For the example above, Truck inherits the feature wheels with multiplicity 4..8 from Vehicle. The part usage truck further inherits wheels with multiplicity 4..8 from Truck. The part usage truck can subset wheels by defining frontLeftWheel, frontRightWheel, rearLeftwheel1, and rearRightWheel1, each with multiplicity 1..1, together giving the minimum total multiplicity of 4. The truck usage can then define additional subsets of wheels, such as rearLeftwheel2, and rearRightwheel2, with multiplicity 0..1, indicating they are optional.
Redefinition is a kind of subsetting. While, in general, a subsetting usage is an additional feature to the subsetted usage, a redefining usage replaces the redefined usage in the context of redefining usage. For the example above, Vehicle contains a feature called fuel that is defined by Fuel. Truck inherits fuel from Vehicle. The part usage truck would then normally inherit fuel as defined by Fuel from Truck. However, truck can instead redefine fuel to restrict its definition to DieselFuel, a subclassification of Fuel. In this case, the new redefining feature replaces the fuel feature that would otherwise be inherited, meaning that the fuel of the truck part must be defined by DieselFuel.
A usage, particularly one with nested usages, can be reused by subsetting it. For example, subsetting the part usage vehicle is analogous to specializing the part definition Vehicle. Suppose vehicle1 is a part usage that subsets vehicle, with the parts-tree decomposition described above. This enables vehicle1 to inherit the features and structure of vehicle. The part usage vehicle1 can be further specialized by adding other part usages to it, such as a body and chassis, and it can redefine parts from vehicle as needed. For example, vehicle1 may redefine engine to be a 4-cylinder engine. The original part vehicle remains unchanged, but vehicle1 is a unique design configuration that specializes vehicle. Other part usages, such as vehicle2, could be created in a similar way to represent other design configurations.
Note. If the part definition Vehicle is modified, the modification will propagate down through the specializations described above. However, it is expected that if Vehicle is baselined in a configuration management tool, then a change to Vehicle is a new revision, and it is up to the modelers to determine whether to retain the previous version of Vehicle or move to the next revision.
Variability
Variation and variant are used to model variability typically associated with a family of design configurations. A variation (sometimes referred to as a variation point) identifies an element in a model that can vary from one design configuration to another. One example of a variation is an engine in a vehicle. For each variation, there are design choices called variants. For this example, where the engine feature is designated as a point of variation, the design choices are a 4-cylinder engine variant or a 6-cylinder engine variant.
Variation can apply to any kind of definition or usage in the model (except for enumeration, see
7.8
). The variation element then specifies all possible variants (i.e., choices) for that variation point. For example, the specified variants for the engine variation are the 4-cylinder engine and the 6-cylinder engine.
Variants are usage elements. If the containing variation is a definition, then each of its variants is implicitly defined by the variation definition. If the containing variation is a usage, then each of its variants implicitly subsets the variation usage. For example, the 4-cylinder engine and the 6-cylinder engine are subsets of all possible engines.
Variations can be nested within other variations, to any level of nesting. For example, the 6-cylinder engine variant may in turn contain cylinders with a variation for bore diameter that includes variants for small-bore diameter and large-bore diameter. Alternatively, the bore diameter variation could be applied more generally to the cylinder of engine, enabling both the 4-cylinder engine and the 6-cylinder engine to have this variation point.
A model with variability can be quite complex since the variation can extend to many other aspects of the model including its structure, behavior, requirements, analysis, and verification. Also, the selection of a particular variant often impacts many other design choices that include other parts, connections, actions, states, and attributes. Constraints can be used to constrain the available choices for a given variant. For example, the choice of a 6-cylinder engine may constrain the choice of transmission to be an automatic transmission, whereas the choice of a 4-cylinder engine may allow for both an automatic transmission or a manual transmission.
Variations and variants are used to construct a model that is sometimes referred to as a superset model, which includes the variants to configure all possible design configurations. A particular configuration is selected by selecting a variant for each variation. SysML provides validation rules that can evaluate whether a particular configuration is a valid configuration based on the choices and constraints provided in the superset model. Variability modeling in SysML can augment other external variability modeling applications, which provide robust capabilities for managing variability across multiple kinds of models such as CAD, CAE, and analysis models, and auto-generating the variant design configurations based on the selections.
Note. The approach to variability modeling in SysML is intended to align with industry standards such as ISO/IEC 26580:2021 Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering.
Graphical Compartments
The graphical notation for a definition or usage may include one or more compartments, which show member elements (if any) using textual or graphical notation. In the graphical symbols in all Representative Notation tables in
Clause 7
, the term compartment stack is a placeholder for any valid compartment for the model element.